Under Windows NT (or any operating system, for that matter), hardware problems are usually less of an issue than software problems. The reason is fairly easy to understand. Hardware problems usually fall into two easily recognized groups: compatibility and catastrophic.
Catastrophic errors can include subtle problems such as loss of functionality. In most cases, though, you can quickly determine that a catastrophic failure has occurred because the device no longer works. You try to access a hard or floppy drive and nothing happens. Trying to use a faulty modem might mean that it picks up the phone line but refuses to dial. Figuring out the sources of these kinds of problems is easy; fixing them is even easier (albeit expensive, for the most part).
Note: Unlike other versions of Windows, Windows NT provides extensive system-monitoring features that you can use as part of your catastrophic failure monitoring strategy. An increase in the amount of network traffic for a particular workstation, for example, might not indicate anything more than a bad cable or a failing network interface card (NIC). Chapter 3's section, "Monitoring the Results of Performance Enhancements," covered the monitoring capability that Windows NT provides, so I won't cover it again here.
The fact that you can't use real-mode device drivers under Windows NT is a real problem for companies with older machines. Upgrading every piece of equipment can be an expensive proposition. The lack of real-mode driver support also means reduced compatibility problems and a higher level of reliability, however. It always pays to look at the good with the bad. I wish I could say that compatibility issues are a thing of the past, but I can't quite go that far. You'll still find NICs that won't work under Windows NT, as well as a long list of ancient equipment that isn't supported at all (the definition of compatibility would have to include equipment that isn't supported because this older hardware isn't compatible with Windows NT). Fortunately, compatibility problems are fairly easy to fix under Windows NT. You'll probably get a symptom in which a device looks as if it failed, but later testing shows that it hasn't. I've already covered some of the solutions for this type of problem. For the most part, you'll find that they're easy to trace and fix.
Before the dart you're throwing hits my head, think about the Windows NT environment for a second. Why did you buy this version of Windows rather than Windows 95? In most cases, it's because of the added reliability and security that Windows NT provides. Running mission-critical applications is one of the biggest reasons that corporate America didn't buy into Windows 95.
The same two features (reliability and security) that make Windows NT such a pleasure to use also hinder the efforts of the person trying to diagnose hardware failures. I've actually worked on several machines where Windows NT led me to believe that one component had failed when it was actually something totally different. The fact that an application has no direct access to the hardware means that it can't really "talk" to the device and ask it what is wrong.
For that reason, I usually try to provide some type of alternative environment for troubleshooting hardware failures. Some diagnostic tools come with their own operating system or reside on a board that troubleshoots the system at the hardware level. In most cases, these diagnostic aids are a bit of a challenge to use, so I use DOS-based utilities as my first line of defense and reserve these other tools for situations in which the DOS-based products can't get the job done for me. Using DOS-based utilities also allows me to include hardware vendor-specific diagnostic aids with my tools. Every major display adapter vendor I know of includes a diagnostic disk with its product, for example, and that disk is usually DOS-based.
You don't have to maintain a DOS partition on your machine if you don't want to, but I consider it a good idea. I usually keep a small 10MB partitionjust large enough to hold my diagnostic aids and a copy of DOS. As an alternative, you can always resort to using floppy disks to hold the diagnostic tools. Obviously, this isn't the best choice because you'll spend some amount of time swapping floppy disks back and forth, but it works.
Figuring out a catastrophic error usually takes a little time and a few hardware and software tools. You also need the knowledge required to use these tools. Here's a typical scenario. You start your machine in the morning and Windows NT comes up fine, but you can't use the mouse. After a little looking around, you find that there aren't any conflicts and you haven't installed anything new recently. The most probable cause of your problem is some type of hardware failure. At least, that's a good place to start searching for a problem that doesn't appear on the Device Manager page of the System Properties dialog box as some type of conflict or other problem.
All kinds of problems fall into the catastrophic category. A crimped cable normally causes some type of hardware failure, for example. It might be as simple as a device that won't respond or a network connection that seems to work intermittently. Port failures don't happen often, but they do happen. You'll also find that NICs fail from time to time. Everyone knows that hard drives fail.
Part of the problem for a network administrator or a home user is figuring out how to find the problem for certain. Easter-egging is the solution that some people use. They just replace one component at a time until they locate the problem. Unfortunately, that's really not the best way to do things. Using diagnostic aids and other troubleshooting tools will save you a lot more time than they cost. It's also a lot less expensive to find the right component the first time and replace it.
Tip: Never discount the usefulness of hardware-specific diagnostic aids. Most sound board and display adapter vendors include a complete diagnostic for their product as part of the package. Some hardware vendors are starting to include this feature with motherboards and other major components as well. I even found one motherboard vendorHauppaugethat provides a diagnostic disk with its products. The diagnostic tests basic motherboard functionality and any installed memory.
Let's look at some of the diagnostic aids I've found helpful in the past. The following sections aren't designed to be an inclusive list of every tool that you'll ever need, but you might find that they provide just enough help so that you can get through a repair with a minimum of effort. I'm concentrating on DOS-based utilities because I feel that they provide the optimum test results. You'll also look at a few of the Windows-specific diagnostic aids. You might find that the convenience of using a Windows utility outweighs all other factors if you only need to maintain one machine.
Peter's Principle: Using DOS versus a Windows Diagnostic Program
Windows applications provide an ease of use that makes most DOS applications look totally unusable in comparison. That's the point in their favor. You can rely on most Windows diagnostics to provide very useful and easy-to-read information. They find a great majority of the hardware problems you could experience as well. Early entries in this field were unsuited to this task, but I could probably feel comfortable using a Windows diagnostic aid for many types of troubleshooting today.
Newer versions of Windows diagnostic programs also include features that their DOS counterparts can't provide. The latest version of WinCheckIt, for example, provides resource-monitoring tools and the capability to optimize multimedia hardware such as your CD-ROM drive. It also helps you if your SYSTEM.INI or other system files become corruptedat least to a certain extent.
One of the problems you'll run into with Windows diagnostic aids under Windows NT is that most vendors won't guarantee the results. TouchStone, the maker of WinCheckIt, only lists Windows 3.x and Windows 95 as suitable platforms, for example. This means that you have to use WinCheckIt under Windows NT at your own risk.
As I mentioned before, there isn't any reliable way to completely test your hardware from within Windows. Although a product such as WinCheckIt provides you with a superior level of Windows-specific information, you just can't count on it to provide the ultimate level of hardware support. The multitasking nature of the operating system makes this impossible. Some diagnostic programs need total access to the hardware as well, and Windows won't allow this kind of access.
There's another problem with Windows diagnostic programssomething that won't occur to most people until it's too late. What happens if you can get DOS up and running but a hardware conflict or failure prevents Windows from starting? I've experienced this particular problem more than a few times. Using a DOS diagnostic means that if the system will boot at all, you can at least figure out what's going on.
The bottom line? Most of the time, you'll find that a Windows product works fine for a home user with one PC to worry about and little capability of fixing some of the more difficult problems. As soon as you move into a corporate environment and have more than one PC to work with, it's imperative that you work with something a little more reliable.
Note: Although you could probably at least run the DOS diagnostic products from within the Windows DOS box, the results you'll get are inaccurate at best. Always run your diagnostic programs in a separate DOS partition; that way, you know you're getting a complete diagnostic check of the system. Windows NT allows you to maintain a separate DOS partition; it displays an option to start it when you start your machine. Chapter 4, "Setup Primer," tells you how to create a multiple boot setup.
Microsoft Diagnostic (MSD) has been around for a long time. Microsoft includes it with both DOS and Windows but doesn't install it to your hard drive with Windows NT. (It installs WinMSD in its place; see the Tip that follows.) The current product version shipping with Windows NT is 2.13. That's the same version that has been around for quite some time now.
Tip: Windows NT includes a Windows version of MSD called WinMSD. You'll get just about the same results with the Windows version of MSD as you will with the DOS version, because this isn't a low-level diagnostic. (In fact, some people probably wouldn't consider it that much of a diagnostic at all.) You can also use this utility with any Windows 95 workstations you maintain. This version of MSD won't work with your Windows 3.x workstations because it uses the Win32 interface.
The original purpose of creating MSD was to provide Microsoft technicians and beta support staff with a full accounting of the capabilities that your machine provides. Figure 25.1 shows that this is still the main purpose of the DOS version of this program. MSD helps detect any hardware you have installed on your machine. It also has command-line parameters for compiling this information to a file that you can use for future reference, as Table 25.1 shows.
Figure 25.1. The opening MSD display shows the types of hardware MSD will detect for you.
Switch | Description |
/B | Switches MSD to a white-on-black display mode. This is handy for running MSD on LCD displays. |
/I | Tells MSD to bypass initial hardware detection. Use this setting if your hardware seems to freeze every time you enter MSD. Some detection phases interfere with normal hardware operations on some machines. |
/F <d>:<p><f> | This is one of the automated report settings. It asks the user to provide a name, address, and telephone number before it produces the report. MSD inserts these items into the report. I find it handy to use this feature to insert a machine name and location instead of the intended information. You also need to supply the following report information: d contains the drive letter, p contains the path, and f contains the file name. Notice the space between the /F and the drive letter. MSD won't recognize the switch if you don't include the space. |
/P <d>:<p><f> | The /P switch does the same thing as the /F switch, except that it doesn't ask for the user's name and address first. |
/S <d>:<p><f> | Use this switch to produce a summary instead of a full-length report. The summary report contains only the very basics about your computer: processor type, memory types and sizes, video type, network type and vendor name, operating system version numbers, mouse type and vendor, other adapter type, drive listing, and port listing. Omitting the filename sends this report to the screen. |
The main reason for using MSD is to detect all your functional hardware. The key word, of course, is functional. If you run MSD and find that it doesn't detect something, there's a pretty good chance that one of two things occurred. Either the driver required to turn on the device isn't present, or the device has failed. If you can eliminate the first cause, you have found the cause of a hardware failure.
MSD is pretty limited as far as diagnostic aids go, but you can use it in a pinch. The reason I prefer the DOS version over its Windows counterpart is that the DOS version is less susceptible to errors introduced by the operating system (this probably won't remain true forever as vendors create better Windows drivers). On the other hand, the Windows version does accurately detect serial port types in most casessomething the DOS version still has a problem doing. If you're maintaining more than one machine, I recommend that you use MSD for its intended purposehardware inventoryand go with a diagnostic aid that provides just a little more input.
Finding an inexpensive troubleshooting aid can be quite difficult. At about $45 for the DOS or Windows version, CheckIt is quite a deal for someone who needs to find simple workstation problems quickly. It's much more than a hardware inventory program. It also includes a variety of diagnostics, a virus scanner, a hard disk formatter, and a floppy disk alignment checker. This is essentially a total workstation diagnostic on a disk. In fact, you can place both of the DOS version CheckIt 360KB floppy disks on one 1.2MB or 1.44MB disk and have plenty of room left over for the DOS boot file and your network drivers.
CheckIt provides three important pieces of machine configuration information. All three of them appear on the System Configuration menu. First, the configuration display, shown in Figure 25.2, helps you see exactly how much memory the workstation has installed and gives you an overview of how the memory is used. This same display provides you with basic workstation configuration information. It tells you whether the workstation has a mouse installed, for example.
The memory display shown in Figure 25.3 provides you with a detailed look at how the workstation uses the memory it has installed. You can use this display to find the location of ROM chips and to optimize the workstation's environment. More important, it might alert you to special hardware needs you should consider when configuring Windows NT. It notifies you of any BIOS overlaps that could cause problems when starting the system, for example.
Figure 25.2. CheckIt provides a variety of information about the devices installed on your machine.
Figure 25.3. You can use CheckIt to determine your current memory settings, but this display is a little outdated.
The final display, shown in Figure 25.4, depicts interrupt usage. This is another factor you should take into consideration when you need to make an update to the system. You need to know whether the machine has a free interrupt to use as required by the new hardware. Notice that this display also includes DMA channel usage. Few products provide you with this information, but it's essential to today's PC user. Many multimedia cards rely on a DMA channel to perform their work, for example. Fortunately, Windows NT provides you with a detailed listing of port addresses, interrupts, and DMA addresses. This display could help you find out about devices that don't register properly in Windows NT for any number of reasons, however.
Figure 25.4. This CheckIt display could help with devices that Windows NT doesn't detect.
The System Configuration menu has two other items of minimal importance. These include functions to check the current CMOS setup and device driver listing. Both of these provide additional information that you can use to help maintain the system, but they're not necessarily essential to completing the inventory.
The Diagnostic menu includes the capability to run tests alone or as part of a batch process. Figure 25.5 shows the batch test display. As you can see, it includes all the tests that CheckIt will run. The memory test provided with this particular product is exceptional. The only test that I've found more complete is the one included with the KickStart2 card, which I'll discuss later.
Figure 25.5. CheckIt provides a complete suite of diagnostic programs.
One of the other features that you'll see on this test screen is the batch-mode feature. You can run a set of tests over and over again until you find a particular error. Some types of hardware faults are intermittent in nature or occur only after the machine has been running for a while. CheckIt helps you find both types of errors.
I was also impressed by some of the other features you'll find under the Tools menu, shown in Figure 25.6. The Locate RAM Chips option helps you find a bad set of RAM chips on the motherboard. All you need to do is enter the motherboard chip configuration; the locator takes care of the rest. The virus checker and other options are nice touches as well.
Figure 25.6. The Locate RAM Chips feature helps you quickly find a bad RAM chip.
Nothing beats a Windows diagnostic program for ease of use. At $50, WinCheckIt is only slightly more expensive than its DOS counterpart, and you'll gain the benefit of the Windows interface. In addition, the 4.x version of WinCheckIt provides full 32-bit support and some special Windows 95 features. What you'll lose in exchange is some of the detailed diagnostics that the DOS version of the product provides, but I'll get into that in a few moments.
When you start WinCheckIt for the first time, it does an inventory of your machine. I found that the inventory was fairly complete, but it missed some of my hardware the first time around (a second run of the check found the missing hardware). The program also misinterpreted my network, informing me that I had NetWare installed when I was using a Microsoft Network for the purposes of this test. WinCheckIt did figure out what kind of serial ports I had and properly noted that I had one bidirectional parallel port. (You can rerun the inventory any time by clicking the Collect button.)
After WinCheckIt collects all this information, you'll see a main screen like the one shown in Figure 25.7. Notice the four dial indicators. They tell you about your current resource status, including the largest available block of system memory, system resource status, free memory below 1MB, and disk space used. A DOS program wouldn't provide you with this type of information. Then again, you can easily obtain this kind of information from other sources, although in a less user-friendly format. The System Summary information is on par with the DOS version of CheckIt. Essentially, it tells you what you have installed on your machine in the barest possible terms. I find that this display comes in handy for a quick check of the system. I've been able to fool WinCheckIt in several ways in the past, however. Using some types of communications programs before I run the collection utility, for example, causes WinCheckIt to tell me that I don't have a modem installed. As previously mentioned, it never did figure out what kind of network I had installed.
Figure 25.7. WinCheckIt provides quick access to its features and gives you a summary of your system's resources.
Across the top of the display you'll find some very handy buttons. I'm not going to show you every one of them, but there are a few that deserve special mention. Clicking the CD-Test button displays the dialog box shown in Figure 25.8. Notice that this isn't just a CD-ROM drive test; it's an actual check of your machine's capability to run multimedia programs. There are three levels of compliance that you can check, as shown in the figure. My test machine failed the second two Multimedia PC Marketing Council (MPC) compliance tests because of the way WinCheckIt performed the check. It looked at only my first hard drive partition. Even though the test machine had more than 850MB of drive space available, WinCheckIt reported a mere 60MBthe amount on the first drive partition.
Figure 25.8. You can use WinCheckIt to determine the multimedia status of a workstation.
I found that the modem tester provided in this utility far exceeded anything I could find in a DOS utility. Not only does it test local modems, but it can test a remote connection as well. To access this test, click the Modem button. WinCheckIt displays a dialog box that asks whether you want to run a local or a remote test. If you select a remote test, you need to provide a telephone number to access the remote modem. When WinCheckIt completes the test, you see a dialog box like the one in Figure 25.9. I found that the report provided by WinCheckIt is superior to the one you can get from Windows 95 and Windows NT; the tests are also a little more thorough. (Obviously, Windows 3.x doesn't even provide modem diagnostics.)
Figure 25.9. Checking the status of your modem is one of the better features of WinCheckIt.
Now let's get down to the feature that you really wanted to hear about: the capability to test your hardware. Unlike most of the other features, you'll actually have to use the Tests menu to check a piece of hardware. This menu has a Test Everything option, along with the capability to test separate subsystems. WinCheckIt examines everything you ask it to and then displays the test results window shown in Figure 25.10. You can scroll through the entire report or simply select specific subsystems by using the drop-down menu.
Figure 25.10. WinCheckIt provides you with a detailed list of the tests it performed along with the test results.
In addition to the things I've already shown you, WinCheckIt provides a wealth of user-related features that don't have a lot to do with diagnosing hardware problems. The Software Shopper utility is a database of more than 2,000 products. You can use WinCheckIt to compare the capabilities of your system with the needs of the product. WinCheckIt provides a list of any upgrades you need to make to your system before you can use the software product. Clicking the Benchmark button takes you to a display that allows you to test your system extensively. It also includes the capability to compare your system to a variety of test systems. This is nice to have, but it is not really essential.
Of all the features that WinCheckIt provides, the Tune-Up button seems the most useless. It's supposed to defragment system memory and enhance performance. The monitor did display a slight improvement on my test systems, but I couldn't see it in any concrete way. Your results might vary from the ones I received, but this particular feature of other programs has certainly received a lot of bad press lately.
What's missing from this program? If you didn't notice already, I didn't say a word about burn-in tests or any of the other things you would normally associate with a heavy-duty diagnostic program. You won't find these features in WinCheckIt either. Overall, it's a lightweight diagnostic aid at best. You would probably be better off looking at TouchStone's DOS product if you need something substantial.
Running a diagnostic using any operating system is risky business. The problem is that the operating system can actually interfere with your ability to find a problem. This is less of a problem under DOS than under Windows, because the diagnostic can simply bypass the operating system, but the problem is real.
PC-Technician seemed a little expensive when I first looked at it. Expect to pay at least $200 for this comprehensive diagnostic. The thing that sets it apart from CheckIt isn't the tests it runs, but the fact that it runs them without an operating system such as DOS. (You'll find that PC-Technician runs about the same tests as CheckIt does, but doesn't provide a batch mode.) All you do is place the floppy disk in a drive and boot the machine. The next thing you'll see is the PC-Technician display.
The fact that PC-Technician doesn't need an operating system is a big advantage in several ways. First, you can use PC-Technician on any machine, even if your company uses several different operating systems. Second, using this product means that you don't have to have a functional hard drive to test the machine. Of course, CheckIt can say the same thing if you use the DOS version of the product. Third, you don't need to worry as much about viruses affecting the results of your tests. The non-DOS format of the PC-Technician disk makes it more difficult for a virus to infect it. Still, Windsor Technologies does provide some information on virus prevention that you should follow.
What do you do when your machine won't boot at all? You can't use a diagnostic aid such as PC-Technician because it needs a functional floppy drive system and a machine that will at least marginally boot to do its work. Easter-egging the problem might seem like the only way to go in this situation. After all, only a few things can keep a PC from booting at all, and it wouldn't take very long to replace them. However, there is a better way.
There are many different ways to monitor a PC. One of them is by checking the power-on startup test (POST) results by intercepting the contents of port 80h. Using this port is a well-documented method of monitoring the progress of your system startup tests. As your system tests itself, it sends the test number over port 80h. All you need to do to find a particular system fault is to see at which test number the machine stops. You'll also need a listing of the test numbers from the vendor or the test card manufacturer. Fortunately, Landmark provides a book that contains the POST codes for most of the common BIOS chips. You can refer to this book whenever you need to test a machine that won't boot.
The KickStart1 card is an unimposing diagnostic aid. It contains only 12 LEDs and three chips. The first four LEDs monitor the power supply to within 10 percent of its specified rating. If one of the lights is out, it's time to replace the power supply.
The other eight LEDs provide output from port 80h. They read as a binary counter. The first four LEDs form the first number, and the second set of four LEDs forms the second number. If lights 1, 2, and 4 are lit, for example, the first number is Bh. This decoding process is somewhat error-prone, however. You could easily see the POST code as 1Ah, when in reality, it is 1Bh. This difference of 1 can make all the difference in the world in finding the problem.
Some BIOS chips don't provide a port 80h output. In that case, you'll need a special test BIOS that Landmark sells to go with its KickStart cards. The advantage of using this special BIOS is that it's fully documentedbetter documented, in fact, than just about any other vendor's BIOS that you'll find. It's unfortunate that you have to buy it as a separate item. Landmark currently sells one test BIOS for each major type of PC.
The advantage of this model of KickStart card is price. You can get a KickStart1 card for less than $100. The disadvantage is that it provides only the bare bones of diagnostic aid. It won't help you find anything beyond power supply failures and clues that the POST codes can supply.
The KickStart2 card is the younger brother of the KickStart1 card. This diagnostic aid also monitors port 80h and provides you with four LEDs for monitoring the power supply. Instead of using LEDs for the port 80h output, however, this card outputs the actual numbers, making it less likely that you'll misinterpret the POST results. (Two alphanumeric LEDs are mounted on the board.) The power supply LEDs also provide a little more flexibility. A switch allows you to select between a monitoring power of 2.5 percent or 5 percent of the rated voltage. This means that you can monitor a power supply to a closer tolerance than with the KickStart1 board.
Besides these enhanced features, the KickStart2 board provides an assortment of additional features. The diagnostic aid doesn't end with monitoring port 80h and checking the power supply levels. This card also provides a set of intense diagnostics in ROM. One of the reasons to use a ROM-based diagnostic is that these diagnostics are unaffected by the operating system or other software problems. The ROM-based diagnostics on the KickStart2 card initialize before the system loads the operating systema handy feature for times when you need to decide whether the hardware or software is the source of the problem with the workstation.
The diagnostics on the KickStart2 board do a lot more and less than standard software diagnostics. The memory tests are much more intense. You can find a problem in the memory support chips, for examplea problem that most software solutions can't locate. Some of the video and input device tests are less powerful than those provided by software aids, but this is a minor problem considering the purpose of buying such a card.
If you want to communicate with the outside world, the KickStart2 card provides the means. It comes equipped with both a parallel and a serial port. The parallel port allows you to troubleshoot a motherboard even if no other peripheral cards are attached. By default, the KickStart2 card sends the results of every test it runs to both the display and the seven-segment LEDs on the card. This provides you two ways of viewing test results. Unfortunately, you can't obtain detailed test results by viewing the LEDs. You can choose to send the test results to the printer, however. Even though this might waste a little paper, it does allow you to see what's happening with the faulty workstation. You can use the serial port to connect the test machine to another machine. This allows you to use the other machine's display and input devices to troubleshoot a nonfunctional workstation. In fact, you could even use this technique to call an intermittent machine via modem when the remote machine's user sees a problem. Rebooting the failed machine takes you directly to the KickStart diagnostic program.
As you can see, the KickStart2 board is a formidable aid in diagnosing difficult workstation failures. It can save you a lot of time and effort in finding problems that software solutions can't handle. In addition, it might provide one of the best ways to separate the hardware from the software so that you can see which component is causing your problem.
You can't fully test the serial and parallel ports in a workstation without loopback plugs. These plugs pass the signal from the port's output back to its input. To create a loopback plug, you use a blank connector without wires and then connect wires between specific pins. Most of the high-end diagnostic programs you buy (such as PC-Technician) provide these plugs. Others, such as CheckIt, don't provide them.
Table 25.2 provides you with the pin connections for a parallel port. Every parallel port uses a 25-pin male connector. Another designation for this type of connector is DB25P. You need to create two connectors to test serial ports. There are 9-pin and 25-pin serial ports. Every serial port uses a female connector. The designation for a 9-pin serial port is DB9S. Table 25.3 lists the pin connections for a 9-pin serial port. The designation for a 25-pin serial port is DB25S. Table 25.4 gives you the pin connections for a 25-pin serial port. You can find the blank connectors and wire you need at most electronics stores.
First Pin | Connected to Second Pin |
11 (Busy +) | 17 (Select Input ) |
10 (Acknowledge ) | 16 (Initialize Printer ) |
12 (Paper Out +) | 14 (Autofeed ) |
13 (Select +) | 01 (Strobe ) |
02 (Data 0 +) | 15 (Error ) |
First Pin | Connected to Second Pin |
02 (RD: Received Data) | 03 (TD: Transmitted Data) |
07 (RTS: Request to Send) | 08 (CTS: Clear to Send) |
06 (DSR: Data Set Ready) | 01 (CD: Carrier Direct) |
01 (CD: Carrier Detect) | 04 (DTR: Data Terminal Ready) |
04 (DTR: Data Terminal Ready) | 09 (RI: Ring Indicator) |
First Pin | Connected to Second Pin |
03 (RD: Received Data) | 02 (TD: Transmitted Data) |
04 (RTS: Request to Send) | 05 (CTS: Clear to Send) |
06 (DSR: Data Set Ready) | 08 (CD: Carrier Direct) |
08 (CD: Carrier Detect) | 20 (DTR: Data Terminal Ready) |
20 (DTR: Data Terminal Ready) | 22 (RI: Ring Indicator) |
As you can see, the pin connections are relatively easy to make. Whether you buy premade loopback plugs or make your own, this is an essential tool for your toolkit. Without loopback plugs, you will never know whether the serial or parallel port you tested really works.
Network administrators, especially those managing large networks, can spend a lot of time tracing cables. People are forever abusing cables in ways that would seem impossible unless you actually looked at the damage. If you're a network administrator, a cable scanner is the most important tool you can get for your toolkit. An average cable scanner costs about $1,000, although you can usually find them a little cheaper. Alternatively, you could build your own cable scanner using plans in some electronics magazines for about $200. Circuit Cellar INK's October/November 1992 issue, for example, contains a set of plans on page 22.
One of the better cable scanners on the market is the Cable Scanner from Microtest. (Microtest provides many other cable scanners with more features, but the Cable Scanner model provides the minimum feature set you need to maintain a network.) This product tests for opens, shorts, and improper terminations. It tells you the distance from your current location to the cable fault. In most cases, all you need to do is track the cable for the required distance and you'll find the problem. To help you trace the signal, the main unit outputs a signal that you can pick up on a remote unit. Instead of taking down every ceiling tile in your office, you simply use the remote unit to trace the cable.
You can send the data collected by the Cable Scanner to a serial printer. The unit collects the data, stores it, and allows you to output it later. The Cable Scanner provides both text and graphics output. This is a handy feature for maintaining records on your system. All you need to do is print the results of the cable check and add it to the network documentation.
The Cable Scanner provides a few other unique functions that you might not use very often. It can detect the noise level of the cable on your system, for example. This means that you can reduce the number of packet errors by simply reducing the noise that the packet signal must overcome. You can also interface the Cable Scanner with an oscilloscope. This allows you to actually monitor the signal that flows across the network. An experienced network administrator could use this information to troubleshoot problem installations.
Windows NT requires you to buy updated hardware; there is no easier way to state it. Windows 95 is the hardware-compatibility king when compared to any version of Windows NT. For the most part, any hardware that runs under the DOS and Windows 3.x environment will also run under Windows 95. Even if you have to use a real-mode driver, you should be able to use that old device under Windows 95 if you really want to. The same can't be said of Windows NT. If you want the added reliability and security that any version of Windows NT provides, you need to pay for it. This means that any device you use has to provide a Windows driverpreferably, a 32-bit Windows NT-specific driver. Old hardware just doesn't provide this kind of support in most cases.
Obviously, the issue of compatibility runs even deeper than simply having a driver to work with. Windows NT has to be able to find the device's ROM routines in some cases. It always has to have access to the device's ports and interrupts. Windows NT really does try its best to figure out which interrupts and port addresses are in use, but it doesn't always succeedespecially if you have an eclectic mix of old and new hardware (and 16-bit and 32-bit drivers). The fact that Windows NT doesn't support Plug and Play (like Windows 95 does) doesn't help matters. No automatic checking of actual device settings takes place; every setup is a manual process on the part of the installer. Adding to this problem is the fact that some of these device drivers don't register themselves properly when you load them. A device driver is supposed to register itself in a device chain and provide certain types of information as part of that registration process. If they don't provide the right level of information, Windows NT can't fully detect them. (Yes, it knows that the driver is present, but it can't use the driver to access the hardware.) What happens next is inevitable, given such circumstances. If Windows NT doesn't see the device driver or it thinks that the device is using different settings than it really is, Windows NT might assume that the interrupts and port addresses the device uses are free. The result is that you might find two devices trying to share the same interrupt or port address.
Of course, one of the best ways to eliminate some of the problems is to make a checklist of all your hardware and the settings that each device uses. You need to include port address, interrupts, and the DMA address. Physically check the settings on cards that use jumpers. You might want to use this opportunity to physically check the BIOS revision of your card; an undocumented update could make a big difference in the settings you'll need to use with Windows NT. A software-configurable device usually includes the current settings as part of the setup dialog box in the Control Panel. (If not, you'll want to contact the vendor and ask how to determine the current settings.) All you really need to do is get out the vendor manual and determine what the settings mean.
After you get all the settings written down, check your list for potential conflicts. Windows NT might tell you that there aren't any, but it's possible that you'll find some anyway. Someone I know recently tried to install Windows NT but found that he couldn't do it. The machine he was using included two SCSI adapters. Windows NT recognized one adapter but not the other. The result: Windows NT didn't recognize the CD-ROM drive attached to the second adapter and therefore couldn't install itself properly. Removing the second SCSI adapter and connecting the CD-ROM drive to the first adapter solved part of the problem. At least Windows NT would install. Performance on the network was very slow, however, and the user still experienced some problems. A check with Windows didn't show any device conflicts. However, a physical check of the remaining SCSI adapter showed that it was using the same interrupt as the NIC. (Windows NT had claimed that the NIC was using interrupt 5 and the SCSI adapter interrupt 3.) Physically changing the SCSI adapter's interrupt setting solved the remaining problem.
At times, you might not be sure that you got all the settings right during the first check. You can also determine the equipment settings by viewing the port and interrupt addresses that a device uses with MSD or a diagnostic program such as CheckIt or WinCheckIt. In fact, using this technique coupled with physical inspection of your hardware ensures that you have all the settings for each device. Even if there aren't any conflicts, you should still maintain a complete record of your hardware.
Unfortunate as it might seem, an ill-behaved device driver normally looks like a malfunctioning device rather than a piece of software that Windows NT won't work with. This normally doesn't happen with 32-bit drivers because they are newer than the 16-bit drivers that cause most of the problems. I was surprised when I found myself in this position with an old CD-ROM drive. Fortunately, I was able to get from the vendor a newer driver that did work. This is the solution you should try as well. Many vendors even allow you to download the upgrade directly from their BBS for the price of a phone call. (Make sure that you don't fail to look at on-line services like CompuServe and the Internet for updated drivers as well.)
Some older devices include their own BIOS. Sometimes, the BIOS routines conflict with Windows NT and cause various types of system failures. Most vendors upgrade their BIOSes as time goes on. They fix bugs and perform some types of optimizations. I've never been able to understand why, but hardware vendors are notoriously reluctant to tell anyone about these fixes. If you have an older piece of hardware with a BIOS that is causing problems with Windows NT, see whether the vendor has some type of BIOS upgrade that might fix the problem. Installing a new chip is usually cheaper than buying a new peripheral.
By now, it should be apparent that hardware incompatibility can cover a lot of ground. Everything from misinterpreted settings to a poorly designed device driver can make it appear that your hardware is incompatible with Windows NT. Let's take a look at the hardware-compatibility problem from a procedural point of view:
Incompatible hardware rarely is incompatible (except when you don't have the proper Windows driver for it). There's usually some problem that you can define, given enough time and resources. The question you have to ask yourself is whether that old hardware is really worth the effort. In my case, I replaced the hardware that was giving me problems, which probably saved me time and frustration. Some types of expensive hardware might be worth the effort involved in looking for the cause of incompatibility, but make sure that you'll get some type of payback.
I've mentioned this particular issue a few times before, but it bears repeating. Windows NT doesn't speak real mode. If you have an old device that you absolutely must use and it only comes with a real-mode driver, your best bet is Windows 95. The second scourge of Windows NT is 16-bit drivers. Replace them with 32-bit drivers whenever possible. Still, you really don't want to get rid of those real-mode and 16-bit Windows drivers, and here's why. What happens if you experience some type of failure on your machine? Suppose that Windows NT can't start because of a corrupted file. You could restore it using Backup, but Backup needs Windows NT to run. So what do you do now?
Getting a new copy of the corrupted file from a floppy disk setup of Windows NT wouldn't be too hard, but you're using the CD version and you need Windows NT to gain access to that too. Now you're really in troubleor are you? You really need a boot disk that contains all the drivers needed to activate your hardware. Make sure that you include all the real-mode driver equivalents for your CD-ROM drive and sound board. In fact, you'll want to include everything needed to make your computer fully functional on this disk.
You'll also want to keep a copy of those real-mode drivers around if you test your system using a DOS-based diagnostic program, such as CheckIt. Of course, you can't use a memory manager to load the devices high. Memory managers and diagnostic programs usually don't get along very well. Just load the drivers in low memory to get your testing done. A diagnostic program is usually fairly easy on memory anyway, because the vendor wants it to run on the maximum number of machines possible.
Under DOS, no one cared if you ran the EISA configuration utility. You really should run it in order for Windows NT to function properly (in fact, Windows NT is far more sensitive to this requirement than Windows 95). Part of the Windows NT startup sequence depends on being able to poll the EISA configuration to find out what kind of devices you have installed.
What does the EISA configuration utility do? It places information about each adapter in your machine in an area of CMOS. When you run the configuration utility, you see one blank for each slot that your EISA bus provides. The EISA configuration utility comes with a list of adapters that it supports. All you need to do is select a slot and then select a device from the list of available devices. This tells your motherboard the specifics of the adapter installed in that slot. The configuration utility automatically displays a device name in each slot that you define. After you tell the configuration utility the contents of each slot, you have to supply it with the interrupt, port address, DMA address, and any other configuration information for that device. This is the information that Windows NT uses to configure your machine even if the device drivers or the adapter itself can't supply the required information. It also helps Windows NT locate some types of problems. If Windows NT can't detect a device that the EISA bus says is present, for example, it displays an error message telling you so instead of simply ignoring the device. The configuration utility also allows you to enable or disable some types of motherboard features, such as installed ports. You'll need to consult the manual that came with your motherboard for full details on how to use the configuration utility.
Will anything terrible happen if you don't run the configuration utility? It won't be terrible in most cases, but it will hinder you from making full use of your machine. Without this information, Windows NT won't be able to perform some types of optimizations that it would normally provide for your system, and it could end up running slower as a result. (There are a few places where Windows NT will definitely holler if you don't provide the EISA configuration information; 32-bit EISA hard drive controllers are one of them.)
The problem for most people is that their EISA configuration utilities are out of date, and some peripheral device vendors don't provide the files needed to configure the bus. It's unlikely that you'll find a configuration file for your modem, for example. To solve the first problem, you'll need to contact the vendor to get a new set of configuration files and perhaps a new utility program as well. The second problem might prove a little more difficult. In some cases, your motherboard vendor will be able to help you with a generic file that will take care of the peripheral. In other cases, the vendor who designed the peripheral might have a configuration file that you can use; the vendor just didn't include it with the device. In some situations, though, despite your best efforts, you won't be able to find a configuration file. The thing to do in these cases is to manually configure all the devices in your machine to the best of your ability and hope that Windows NT recognizes the device without an EISA configuration entry (in most cases, it will).
The last kind of hardware I'll address in this chapter is the PCMCIA bus. There has been a problem with this bus since the day it came out. Some cards won't work with your bus. You might plug a card into the slot and it won't work at all. Of course, when you take it back to the place you bought it from, they'll show you that it does work (this is one of the reasons you should take your machine with you if at all possible when you suspect some type of compatibility problem). Even worse, some cards will work with your bus, but only in a certain slot or only with certain other cards. You might find that a modem card works fine in the first slot, but not in any of the others.
Most people have heard about the problems with getting PCMCIA cards to work properly. Finally, there are some standards for making the cards compatible, but only the new cards adhere to these standards. Unfortunately, many cards have already gone out that won't work together, so you need to choose your cards with care. The best piece of advice I can offer is to buy new cards from a vendor that actually allows you to test them with the other cards in your machine.
Make sure that you run a thorough test, using several different combinations of cards to check the new one for compatibility problems. The test should include checking the card in several different slots. I usually test the card under both DOS and Windows. You never know when you'll need to access that card outside the normal Windows environment to take care of some kind of diagnostic.
Use WinMSD to find out about the components installed in your machine. The following procedure will guide you through the process:
Buy a diagnostic program and completely test your systemespecially the hard drives. Make sure that you get a diagnostic that is easy to use and tests everything your machine has to offer. Use the loopback plugs provided with the diagnostic program to test your ports, or create your own loopback plugs using the procedure in this chapter.
Check any real-mode device drivers installed on your system. Make sure that they are the most current drivers the vendor has to offer. Do the same with any peripherals that provide their own BIOS. This includes both modems and display adapters. You'll also find a BIOS on most hard disk controllers and many other devices installed on your machine. Using the most current BIOS not only ensures that you'll have the least number of bugs to contend with, but it could also mean a slight speed boost because of optimizations that the vendor made to it.